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Abstract. Efficient implementations of atomic objects such as concurrent stacks 
and queues are especially susceptible to programming errors, and necessitate 
automatic verification. Unfortunately their correctness criteria — linearizability 
with respect to given ADT specifications — are hard to verify. Even on classes 
of implementations where the usual temporal safety properties like control-state 
reachability are decidable, linearizability is undecidable. 

In this work we demonstrate that verifying linearizability for certain fixed ADT 
specifications is reducible to control-state reachability, despite being harder for ar¬ 
bitrary 1 ADTs. We effectuate this reduction for several of the most popular atomic 
objects. This reduction yields the first decidability results for verification without 
bounding the number of concurrent threads. Furthermore, it enables the applica¬ 
tion of existing safety-verification tools to linearizability verification. 


1 Introduction 

Efficient implementations of atomic objects such as concurrent queues and stacks are 
difficult to get right. Their complexity arises from the conflicting design requirements 
of maximizing efficiency/concurrency with preserving the appearance of atomic behav¬ 
ior. Their correctness is captured by observational refinement , which assures that all 
behaviors of programs using these efficient implementations would also be possible 
were the atomic reference implementations used instead. Linearizability Eh , being an 
equivalent property Si , is the predominant proof technique: one shows that each con¬ 
current execution has a linearization which is a valid sequential execution according to 
a specification, given by an abstract data type (ADT) or reference implementation. 

Verifying automatically^! that all executions of a given implementation are lineariz- 
able with respect to a given ADT is an undecidable problem Si, even on the typical 
classes of implementations for which the usual temporal safety properties are decidable, 
e.g., on finite-shared-memory programs where each thread is a finite-state machine. 
What makes linearization harder than typical temporal safety properties like control- 
state reachability is the existential quantification of a valid linearization per execution. 

In this work we demonstrate that verifying linearizability for certain fixed ADTs 
is reducible to control-state reachability, despite being harder for arbitrary ADTs. We 
believe that fixing the ADT parameter of the verification problem is justified, since in 
practice, there are few ADTs for which specialized concurrent implementations have 
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been developed. We provide a methodology for carrying out this reduction, and instan¬ 
tiate it on four ADTs: the atomic queue, stack, register, and mutex. 

Our reduction to control-state reachability holds on any class of implementations 
which is closed under intersection with regular language^ and which is data indepen¬ 
dent — informally, that implementations can perform only read and write operations on 
the data values passed as method arguments. From the ADT in question, our approach 
relies on expressing its violations as a finite union of regular languages. 

In our methodology, we express the atomic object specifications using inductive 
rules to facilitate the incremental construction of valid executions. For instance in our 
atomic queue specification, one rule specifies that a dequeue operation returning empty 
can be inserted in any execution, so long as each preceding enqueue has a correspond¬ 
ing dequeue, also preceding the inserted empty-dequeue. This form of inductive rule 
enables a locality to the reasoning of linearizability violations. 

Intuitively, first we prove that a sequential execution is invalid if and only if some 
subsequence could not have been produced by one of the rules. Under certain condi¬ 
tions this result extends to concurrent executions: an execution is not linearizable if and 
only if some projection of its operations cannot be linearized to a sequence produced 
by one of the rules. We thus correlate the finite set of inductive rules with a finite set 
of classes of non-linearizable concurrent executions. We then demonstrate that each of 
these classes of non-linearizable executions is regular, which characterizes the viola¬ 
tions of a given ADT as a finite union of regular languages. The fact that these classes 
of non-linearizable executions can be encoded as regular languages is somewhat surpris¬ 
ing since the number of data values, and thus alphabet symbols, is, a priori, unbounded. 
Our encoding thus relies on the aforementioned data independence property. 

To complete the reduction to control-state reachability, we show that linearizability 
is equivalent to the emptiness of the language intersection between the implementa¬ 
tion and finite union of regular violations. When the implementation is a finite-shared- 
memory program with finite-state threads, this reduces to the coverability problem for 
Petri nets, which is decidable, and EXPSPACE-complete. 

To summarize, our contributions are: 

- a generic reduction from linearizability to control-state reachability, 

- its application to the atomic queue, stack, register, and mutex ADTs, 

- the methodology enabling this reduction, which can be reused on other ADTs, and 

- the first decidability results for linearizability without bounding the number of con¬ 
current threads. 

Besides yielding novel decidability results, our reduction paves the way for the applica¬ 
tion of existing safety-verification tools to linearizability verification. 

Section [2] outlines basic definitions. Section [3] describes a methodology for induc¬ 
tive definitions of data structure specifications. In Section [4] we identify conditions un¬ 
der which linearizability can be reduced to control-state reachability, and demonstrate 
that typical atomic objects satisfy these conditions. Finally, we prove decidability of 
linearizability for finite-shared-memory programs with finite-state threads in Section [ 5 ] 
Proofs to technical results appear in the appendix. 

4 We consider languages of well-formed method call and return actions, e.g., for which each 
return has a matching call. 
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2 Linearizability 


We fix a (possibly infinite) set D of data values, and a finite set M of methods. We 
consider that methods have exactly one argument, or one return value. Return values 
are transformed into argument values for uniformity^ In order to differentiate methods 
taking an argument (e.g., the Enq method which inserts a value into a queue) from 
the other methods, we identify a subset M,„ c M of input methods which do take an 
argument. A method event is composed of a method m e M and a data value x e D, 
and is denoted m(x). We define the concatenation of method-event sequences u ■ v in 
the usual way, and e denotes the empty sequence. 

Definition 1. A sequential execution is a sequence of method events, 

The projection u\ D of a sequential execution u to a subset D c D of data values is 
obtained from u by erasing all method events with a data value not in D. The set of 
projections of u is denoted proj(n). We write u \ x for the projection Mp\{.v|- 

Example 1. The projection Enq{\)Enq(2)Deq(\)Enq(3)Deq(2)Deq(3) \ 1 is equal to 
Enq(2)Enq(3)Deq(2)Deq(3). 

We also fix an arbitrary infinite set O of operation (identifiers). A call action is 
composed of a method m e M, a data value r e D, an operation o e O, and is denoted 
call 0 m(x). Similarly, a return action is denoted ret 0 m(x). The operation o is used to 
match return actions to their call actions. 

Definition 2. A (concurrent) execution e is a sequence of call and return actions which 
satisfy a well-formedness property: every return has a call action before it in e, using 
the same tuple m, x, o, and an operation o can be used only twice in e, once in a call 
action, and once in a return action. 

Example 2. The sequence call 0l Enq(l) ■ call 02 Enq(A) ■ ret 0l Enq(l) ■ ret 02 Enq(A) 
is an execution, while call 0l Enq(l) ■ call 02 Enq(A) ■ ret 0l Enq(l) ■ ret 0l Enq(A) and 
call 0l Enq(l) • ret 0l Enq(l) • ret 0z Enq{A) are not. 

Definition 3. An implementation I is a set of (concurrent) executions. 

Implementations represent libraries whose methods are called by external programs, 
giving rise to the following closure properties 0], In the following, c denotes a call 
action, r denotes a return action, a denotes any action, and e, e' denote executions. 

- Programs can call library methods at any point in time: 
e-e'el implies e ■ c ■ e' e I so long as e ■ c ■ e' is well formed. 

- Calls can be made earlier: 

e ■ a ■ c ■ e' e I implies e ■ c ■ a ■ e' e I. 

5 Method return values are guessed nondeterministically, and validated at return points. This 
can be handled using the assume statements of typical formal specification languages, which 
only admit executions satisfying a given predicate. The argument value for methods without 
argument or return values, or with fixed argument/return values, is ignored. 
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- Returns been made later: 

e ■ r ■ a ■ e' e I implies e ■ a ■ r ■ e' e I. 

Intuitively, these properties hold because call and return actions are not visible to the 
other threads which are running in parallel. 

For the remainder of this work, we consider only completed executions, where each 
call action has a corresponding return action. This simplification is sound when im¬ 
plementation methods can always make progress in isolation ES: formally, for any 
execution e with pending operations, there exists an execution <?' obtained by extending 
e only with the return actions of the pending operations of e. Intuitively this means that 
methods can always return without any help from outside threads, avoiding deadlock. 

We simply reasoning on executions by abstracting them into histories. 

Definition 4 . A history is a labeled partial order (O, <, /) with O c Q and l : O —> 

M x D. 

The order < is called the happens-before relation , and we say that o\ happens before 02 
when o\ < 02■ Since histories arise from executions, their happens-before relations are 
interval orders 0|]: for distinct o\, 02,03,04, if o\ < 02 and 03 < 04 then either o\ < 04, 
or o 3 < 02- Intuitively, this comes from the fact that concurrent threads share a notion 
of global time. D/,cD denotes the set of data values appearing in h. 

The history of an execution e is defined as (O, <, l) where: 

- O is the set of operations which appear in e, 

- o\ < o 2 iff the return action of cq is before the call action of 02 in <?, 

- an operation o occurring in a call action call 0 m(x) is labeled by mix). 

Example 3 . The history of the execution call 0l Enq{l) ■ cal\ 02 Enq{ 4 )-ret 0l Enq(l)- 
ret 02 Enq( 4 ) is ({01,02}, <, 0 with l{o\) = Enq(l), l{of) = Enq{ 4 ), and with < being 
the empty order relation, since o\ and 02 overlap. 

Let h = ( O, <, Z) be a history and 11 a sequential execution of length n. We say that h 
is linearizable with respect to u, denoted h c u, if there is abijection/ : O —> {1} s.t. 

- if o\ < o 2 then/(oO < /(o 2 ), 

- the method event at position /(o) in u is Z(o). 

Definition 5 . A history h is linearizable with respect to a set S of sequential executions, 
denoted h C S, if there exists u e S such that h C u. 

A set of histories H is linearizable with respect to S, denoted H C S if h E S for all 
h e H. We extend these definitions to executions according to their histories. 

A sequential execution u is said to be differentiated if, for all input methods m e 
M i„, and every x e D, there is at most one method event m(x) in u. The subset of 
differentiated sequential executions of a set S is denoted by 5 *. The definition extends 
to (sets of) executions and histories. For instance, an execution is differentiated if for all 
input methods m e M,„ and every x e D, there is at most one call action call 0 mix). 

Example 4 . call 0l Enq{l) ■ call 02 Enq(l) ■ ret 0l Enq(l) ■ ret 02 Enq{l) is not differ¬ 
entiated, as there are two call actions with the same input method (Enq) and the same 
data value. 
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A renaming r is a function from D to D. Given a sequential execution (resp., ex¬ 
ecution or history) u , we denote by Hit) the sequential execution (resp., execution or 
history) obtained from u by replacing every data value x by r(x). 

Definition 6. The set of sequential executions (resp., executions or histories) S is data 
independent if: 

- for all u £ S, there exists u' £ S±, and a renaming r such that u = r(u'), 

- for all u & S and for all renaming r, r(u ) 6 S. 

When checking that a data-independent implementation I is linearizable with re¬ 
spect to a data-independent specification S , it is enough to do so for differentiated execu¬ 
tions jl]]. Thus, in the remainder of the paper, we focus on characterizing linearizability 
for differentiated executions, rather than arbitrary ones. 

Lemma 1 (Abdulla et al. [ l||). A data-independent implementation I is linearizable 
with respect to a data-independent specification S, if and only if is linearizable with 
respect to S f . 


3 Inductively-Defined Data Structures 

A data structure S is given syntactically as an ordered sequence of rules R \,..., R n , 
each of the form u\ ■ U2 • • ■ £ S A Guard(u \,..., uf) => Expr(u \,..., uf) £ S, where 

the variables m, are interpreted over method-event sequences, and 

- Guard{u \,..., uf) is a conjunction of conditions on u \,..., iq- with atoms 

• Uj £ M* (M c M) 

• matched (m, n,) 

- Expr(u \,..., uf) is an expression E - a\ ■ az ■ ■ ■ ai where 

• «],..., Uk appear in that order, exactly once, in E, 

• each o, is either some uj, a method m, or a Kleene closure m* (m £ M), 

• a method me M appears at most once in E. 

We allow k to be 0 for base rules, such as e £ S. 

A condition m, £ M* (M c M) is satisfied when the methods used in m, are all in 
M. The predicate matched(m, u,) is satisfied when, for every method event m(x) in 
there exists another method event in m; with the same data value x. 

Given a sequential execution u = u\ •...-Uk and an expression E = Expr(u \,..., uf), 
we define [£’]| as the set of sequential executions which can be obtained from E by 
replacing the methods m by a method event mix) and the Kleene closures nr by 0 or 
more method events mix). All method events must use the same data value x £ D. 

A rule R = u\ -uz- • ■ Mr- £ 5 A Guardiu \,..., uf) => Expr(u \,..., uf) £ S is applied 
to a sequential execution w to obtain a new sequential execution w’ from the set: 

U \Expr(wi,... ,w*)] 

W=Wi-W2—WjfcA 

Guard(w\ ) 
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We denote this w w'. The set of sequential executions [ 5 ] = |/?i,.. .,/?„] is then 
defined as the set of sequential executions w which can be derived from the empty 
word: 


e 



w i 



= w. 


where i\,..., i p is a non-decreasing sequence of integers from {1 ..., nj. This means 
that the rules must be applied in order, and each rule can be applied 0 or several times. 

Below we give inductive definitions for the atomic queue and stack data structures. 
Other data structures such as atomic registers and mutexes also have inductive defini¬ 
tions, as demonstrated in the appendix. 


Example 5 . The queue has a method Enq to add an element to the data structure, and a 
method Deq to remove the elements in a FIFO order. The method DeqEmpty can only 
return when the queue is empty (its parameter is not used). The only input method is 
Enq. Formally, Queue is defined by the rules Ro,REnq^EnqDeq and RDeqEmpn- 

R 0 = ee Queue 

R Enq =ue Queue Rue Enq * => u ■ Enq e Queue 
REnqDeq = u ■ v 6 Queue A u 6 Enq * A v 6 [Enq, DeqY => Enq ■ u ■ Deq ■ v e Queue 
RDeqEmpty = u • v e Queue A matched(f?Hg, u) => u ■ DeqEmpty ■ v e Queue 

One derivation for Queue is: 

REnqDeq 

e e Queue -> Enq( 1) • Deq{ 1) 6 Queue 

REnqDeq 

-> Enq(2) ■ Enq( 1) • Deq( 2) • Deq{ 1) e Queue 

REnq Deq 

-> Enq( 3) • Deq{ 3) • Enq( 2) • Enq( 1) • Deq( 2) • Deq{ 1) e Queue 

RDeqEmpty „ 

- Enq( 3) • Deq( 3) • DeqEmpty ■ Enq( 2) • Enq( 1) • Deq( 2) • Deq( 1) £ Queue 


Similarly, Stack is composed of the rules Ra,Rp U shPop-Rpusi^RpopEmpty 
R 0 = ee Stack 

RpushPop = u ■ v £ Stack a matchedtPiij/t, u) a matched(/ > Hj/7, v) a u,v e [Push, Pop}* 
Push ■ u ■ Pop ■ v e Stack 

R Push = u ■ v e Stack a matchedtPiij/i, u) a u, v e j Push, Pop}" => u ■ Push ■ v e Stack 
RpopEmpty = u ■ v e Stack A matchedtPiij/?, u) => u ■ PopEmpty ■ v e Stack 


We assume that the rules defining a data structure S satisfy a non-ambiguity prop¬ 
erty stating that the last step in deriving a sequential execution in [ 5 ] is unique and it can 
be effectively determined. Since we are interested in characterizing the linearizations of 
a history and its projections, this property is extended to permutations of projections of 
sequential executions which are admitted by S. Thus, we assume that the rules defining 
a data structure are non-ambiguous , that is: 


- for all u e [ 5 ], there exists a unique rule, denoted by last(n), that can be used as 
the last step to derive u, i.e., for every sequence of rules Rj t ,..., R ir leading to u, 
Ri n = last(M). For u i [ 5 ], last(i/) is also defined but can be arbitrary, as there is 
no derivation for u. 
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- iflast(M) =/?,-, then for every permutation u' e [ 5 ] of a projection of u, last(t/) = 
Rj with j < i. If u' is a permutation of u, then last(t/) = R,. 

Given a (completed) history h, all the u such that h c u are permutations of one 
another. The last condition of non-ambiguity thus enables us to extend the function 
last to histories: lasti/z) is defined as last(u) where u is any sequential execution 
such that h c u. We say that lasti/z) is the rule corresponding to h. 

Example 6. For Queue, we define last for a sequential execution u as follows: 

- if u contains a DeqEmpty operation, last(u) = RDeqEmpty, 

- else if u contains a Deq operation, last(zz) = REnqDeq , 

- else if u contains only Enq s, last(u) = Rsnq, 

- else (if u is empty), last(u) = Rq. 

Since the conditions we use to define last are closed under permutations, we get that 
for any permutation ui of it, lastizz) = lastizzo), and last can be extended to histories. 
Therefore, the rules Rq, REnqDeq, RDeqEmpty are non-ambiguous. 


4 Reducing Linearizability to State Reachability 

Our end goal for this section is to show that for any data-independent implementation 
J, and any specification S satisfying several conditions defined in the following, there 
exists a computable finite-state automaton JK (over call and return actions) such that: 

I E S <^=> inji = 0 

Then, given a model of J, the linearizability of I is reduced to checking emptiness of 
the synchronized product between the model of I and J\. The automaton Ih represents 
(a subset of the) executions which are not linearizable with respect to S. 

The first step in proving our result is to show that, under some conditions, we can 
partition the concurrent executions which are not linearizable with respect to S into a 
finite number of classes. Intuitively, each non-linearizable execution must correspond 
to a violation for one of the rules in the definition of S. 

We identify a property, which we call step-by-step linearizability, which is suffi¬ 
cient to obtain this characterization. Intuitively, step-by-step linearizability enables us 
to build a linearization for an execution e incrementally, using linearizations of projec¬ 
tions of e. 

The second step is to show that, for each class of violations (i.e., with respect to a 
specific rule Rj), we can build a regular automaton ih, such that: a) when restricted to 
well-formed executions, J\j recognizes a subset of this class; b) each non-linearizable 
execution has a corresponding execution, obtained by data independence, accepted by 

If such an automaton exists, we say that R, is co-regular (formally defined later in 
this section). 

We prove that, provided these two properties hold, we have the equivalence men¬ 
tioned above, by defining J\ as the union of the J?f’s built for each rule R,. 
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4.1 Reduction to a Finite Number of Classes of Violations 


Our goal here is to give a characterization of the sequential executions which belong to 
a data structure, as well as to give a characterization of the concurrent executions which 
are linearizable with respect to the data structure. This characterization enables us to 
classify the linearization violations into a finite number of classes. 

Our characterization relies heavily on the fact that the data structures we consider 
are closed under projection , i.e., for all u e S. D c B, we have u\o e S. The reason for 
this is that the guards used in the inductive rules are closed under projection. 

Lemma 2. Any data structure S defined in our framework is closed under projection. 

A sequential execution u is said to match a rule R with conditions Guard if there 
exist a data value x and sequential executions u\,..., Uk such that u can be written as 
\Expr(u\ ,..., Mi)], where x is the data value used for the method events, and such that 
Guard(u \,..., uf) holds. We call x the witness of the decomposition. We denote by MR 
the set of sequential executions which match R, and we call it the matching set of R. 

Example 7. MRsnqDeq is the set of sequential executions of the form Enq(x)u-Deq{x)-v 
for some x e B, and with u e Enq*. 

Lemma 3. Let S = R \,... ,R n be a data structure and u a differentiated sequential 
execution. Then, 





This characterization enables us to get rid of the recursion, so that we only have to 
check non-recursive properties. We want a similar lemma to characterize eC5 for an 
execution e. This is where we introduce the notion of step-by-step linearizability, as the 
lemma will hold under this condition. 

Definition 7. A data structure S = Ri,... ,R„ is said be to step-by-step linearizable if 
for any differentiated execution e, ife is linearizable w.r.t. MR , with witness x, we have: 


pfi. Ri] => eE [Ri,...,RJ 


This notion applies to the usual data structures, as shown by the following lemma. 
The generic schema we use is the following: we let u' e p?i,.. .,/?,■] be a sequential 
execution such that e \ x C u' and build a graph G from u', whose acyclicity implies 
that e E p?i,.. .,/?,•]. Then, we show that we can always choose u' so that G is acyclic. 

Lemma 4. Queue, Stack, Register, and Mutex are step-by-step linearizable. 

Intuitively, step-by-step linearizability will help us prove the right-to-left direction 
of Lemma [3 by allowing us to build a linearization for e incrementally, from the lin¬ 
earizations of projections of e. 
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Lemma 5. Let S be a data structure with rules R \,..., R n . Let e be a differentiated 
execution. IfS is step-by-step linearizable, we have (for any j): 

e E Rj\ <=> proj(e) C [j MR, 

i<j 

Thanks to Lemma [5] if we’re looking for an execution e which is not linearizable 
w.r.t. some data-structure S, we must prove that proj(e) f U/ MR,, i.e., we must find a 
projection e' e proj(e) which is not linearizable with respect to any MR, (e' % (J; MR,). 

This is challenging as it is difficult to check that an execution is not linearizable 
w.r.t. a union of sets simultaneously. Using non-ambiguity, we simplify this check by 
making it more modular, so that we only have to check one set MR, at a time. 

Lemma 6. Let S be a data structure with rules R\,... ,R„. Let e be a differentiated 
execution. IfS is step-by-step linearizable, we have: 

cC5 <=> V<?' e proj(e). e’ C MR where R = last(e') 

Lemma[6]gives us the finite kind of violations that we mentioned in the beginning 
of the section. More precisely, if we negate both sides of the equivalence, we have: 
e S <==> 3e' e proj(e). e' MR. This means that whenever an execution is 
not linearizable w.r.t. S, there can be only finitely reasons, namely there must exist a 
projection which is not linearizable w.r.t. the matching set of its corresponding rule. 

4.2 Regularity of Each Class of Violations 

Our goal is now to construct, for each R, an automaton .71 which recognizes (a subset 
of) the executions e, which have a projection e' such that e' % MR. More precisely, we 
want the following property. 

Definition 8 . A rule R is said to be co-regular if we can build an automaton SI such 
that, for any data-independent implementation I, we have: 

Sin I 7=0 <==> 3e e J # , e' e proj(e). last(e') = R A e' % MR 

A data structure S is co-regular if all of its rules are co-regular. 

Formally, the alphabet of S\ is {call m(x) \ m e M,x e DjUjret m(x) \ m 6 M,x e D) 
for a finite subset D c O. The automaton doesn’t read operation identifiers, thus, when 
taking the intersection with J, we ignore them. 

Lemma 7. Queue, Stack, Register, and Mutex are co-regular. 

Proof. To illustrate this lemma, we sketch the proof for the rule RDeqEmpty of Queue. 
The complete proof of the lemma can be found in the extended version of this paper. 

We prove in the appendix (Corollary |T} that a history has a projection such that 
last(/r') = RDeqEmpty and h’ MRoeqEmpty if and only if it has a DeqEmpty operation 
which is covered by other operations, as depicted in Fig. Q] The automaton S\R DeqEmm in 
Fig.|2]recognizes such violations. 
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DeqEmpty{ 2) 


Enq{\) 


| Deq(X) | 


EtiqjX) ^ 


Deq( 1) 


Enq(Y) 

Enq(l) 


| o^d) | 


D«?(l) 


M(3) M(3) M(3) 



Fig. 1. A four-pair RoeqEmpty violation. 
Lemma [T9l demonstrates that this pat¬ 
tern with arbitrarily-many pairs is reg¬ 
ular. 


Fig. 2. An automaton recognizing RoeqEmpty viola¬ 
tions, for which the queue is non-empty, with data 
value 1, for the span of DeqEmpty. We assume all 
call Enq{ 1) actions occur initially without loss of 
generality due to implementations' closure properties. 


Let I be any data-independent implementation. We show that 

^RDeqEmpty X X 0 ■■ 3e £ -Zjt, 6 ptojfc). lclS"t((? ) — RDeqEmpty A 6 MRoeqEmpty 

(=>) Let e e I be an execution which is accepted by XL,■ By data independence, 
let e^el and r a renaming such that e = r(e # ). Let du... ,d m be the data values which 
are mapped to value 1 by r. 

Let d be the data value which is mapped to value 2 by r. Let o the DeqEmpty 
operation with data value d. By construction of the automaton we can prove that o is 
covered by d\,..., d m , and using CorollaryQ] conclude that h has a projection such that 

laSt(/z ) — RDeqEmpty and ll ^ MRoeqEmpty■ 

(<=) Let eq e Ip such that there is a projection e' such that last(e') = RDeqEmpty 
and e' % MRDeqEmpty Let d \,..., d m be the data values given by CorollaryQ] and let d 
be the data value corresponding to the DeqEmpty operation. 

Without loss of generality, we can always choose the cycle so that Enq(d ,) doesn’t 
happen before Deq(di- 2 ) (if it does, drop 

Let r be the renaming which maps d\,.. .,d,„ to 1, d to 2, and all other values to 3. 
Let e = r(ep). The execution e can be recognized by automaton XI R DeqEmply , and belongs 
to I by data independence. 

When we have a data structure which is both step-by-step linearizable and co¬ 
regular, we can make a linear time reduction from the verification of linearizability 
with respect to S to a reachability problem, as illustrated in TheoremQ] 

Theorem 1. Let S be a step-by-step linearizable and co-regular data structure and 
let I be a data-independent implementation. There exists a regular automaton XI such 
that: 

ICS <=> Jnxi = 0 

5 Decidability and Complexity of Linearizability 

TheoremQ] implies that the linearizability problem with respect to any step-by-step lin¬ 
earizable and co-regular specification is decidable for any data-independent implemen- 
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tation for which checking the emptiness of the intersection with finite-state automata is 
decidable. Here, we give a class C of data-independent implementations for which the 
latter problem, and thus linearizability, is decidable. 

Each method of an implementation in C manipulates a finite number of local vari¬ 
ables which store Boolean values, or data values from D. Methods communicate through 
a finite number of shared variables that also store Boolean values, or data values from 
D. Data values may be assigned, but never used in program predicates (e.g., in the 
conditions of if and while statements) so as to ensure data independence. This class 
captures typical implementations, or finite-state abstractions thereof, e.g., obtained via 
predicate abstraction. 

Let I be an implementation from class C. The automata constructed in the proof 
of Lemma [7] use only data values 1, 2, and 3. Checking emptiness of I n id is thus 
equivalent to checking emptiness of 1 3 n J\ with the three-valued implementation 
J 3 = {e e 1 1 e = C|( 1 . 2 , 31 1- The set 1 3 can be represented by a Petri net since bounding 
data values allows us to represent each thread with a finite-state machine. Intuitively, 
each token in the Petri net represents another thread. The number of threads can be 
unbounded since the number of tokens can. Places count the number of threads in each 
control location, which includes a local-variable valuation. Each shared variable also 
has one place per value to store its current valuation. 

Emptiness of the intersection with regular automata reduces to the EXPSPACE- 
complete coverability problem for Petri nets. Limiting verification to a bounded number 
of threads lowers the complexity of coverability to PSPACE @]. The hardness part 
of Theorem Incomes from the hardness of state reachability in finite-state concurrent 
programs. 

Theorem 2. Verifying linearizability of an implementation in C with respect to a step- 
by-step linearizable and co-regular specification is PSPACE-complete for a fixed num¬ 
ber of threads, and EXPSPACE-complete otherwise. 


6 Related Work 


Several works investigate the theoretical limits of linearizability verification. Verifying 
a single execution against an arbitrary ADT specification is NP-complete HI]. Verify¬ 
ing all executions of a finite-state implementation against an arbitrary ADT specifica¬ 
tion (given as a regular language) is EXPSPACE-complete when program threads are 
bounded |}^,@], and undecidable otherwise 0]. 

Existing automated methods for proving linearizability of an atomic object imple¬ 
mentation are also based on reductions to safety verification QG1I ll~2ll . Vafeiadis |12il 
considers implementations where operation’s linearization points are fixed to particular 
source-code locations. Essentially, this approach instruments the implementation with 
ghost variables simulating the ADT specification at linearization points. This approach 
is incomplete since not all implementations have fixed linearization points. Aspect- 
oriented proofs G3 reduce linearizability to the verification of four simpler safety prop¬ 
erties. However, this approach has only been applied to queues, and has not produced a 
fully automated and complete proof technique. Dodds et al. HI] prove linearizability of 
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stack implementations with an automated proof assistant. Their approach does not lead 
to full automation however, e.g., by reduction to safety verification. 

7 Conclusion 

We have demonstrated a linear-time reduction from linearizability for fixed ADT spec¬ 
ifications to control-state reachability, and the application of this reduction to atomic 
queues, stacks, registers, and mutexes. Besides yielding novel decidability results, our 
reduction enables the use of existing safety-verification tools for linearizability. While 
this work only applies the reduction to these four objects, our methodology also applies 
to other typical atomic objects including semaphores and sets. Although this method¬ 
ology currently does not capture priority queues, which are not data independent, we 
believe our approach can be extended to include them. We leave this for future work. 
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8 Appendix 


8.1 Examples 

For all examples, the domain D is the set of natural numbers N. 


Stack Definition of the function last for a sequential execution u: 

- if u contains a PopEmpty operation, lastft/) = Rp„ P Empty, 

- else if u contains an unmatched Push operation, lastft/) = Rp„ s i„ 

- else if u contains a Pop operation, lastft/) = Rp us hPop, 

- else (if u is empty), lastft/) = Rq. 


Register The register has a method Write used to write a data-value, and a method 
Read which returns the last written value. The only input method is Write. Its rules are 
R I j and Rwr ‘ 


Ro = ee Register 

R wr = u e Register => Write ■ Read* ■ u e Register 
Definition of the function last for a sequential execution u: 

- if u is not empty, lastft/) = Rwr, 

- else, lastft/) = Rq. 


Mutex (Lock) The mutex has a method Lock, used to take ownership of the Mutex, 
and a method Unlock, to release it. The only input method is Lock. It is composed of 
the rules Rq, R Lock and R LU : 


R 0 = e e Mutex 
RLock = Lock e Mutex 

R lu sue Mutex => Lock ■ Unlock ■ u e Mutex 

In practice. Lock and Unlock methods do not have a parameter. Here, the parameter 
represents a ghost variable which helps us relate Unlock to their corresponding Lock. 
Any implementation will be data independent with respect to these ghost variables. 
Definition of the function last for a sequential execution u: 

- if u contains an Unlock operation, lastft/) = Rlu, 

- else if u is not empty, lastft/) = Rlocl, 

- else, lastft/) = Rq. 
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8.2 Proofs of Section [4] 

Lemma 1 (Abdulla et al. fill). A datci-independent implementation I is linearizable 
with respect to a data-independent specification S, if and only ifI + is linearizable with 
respect to S f . 

Proof. (=>) Let e be a (differentiated) execution in 1 By assumption, it is linearizable 
with respect to a sequential execution u in S, and the bijection between the operations 
of e and the method events of u, ensures that u is differentiated and belongs to S^. 

(<=) Let e be an execution in I. By data independence of I, we know there exists 
e± e I + and a renaming r such that r{ef) = e. By assumption, is linearizable with 
respect to a sequential execution u± e S t . We define u = r{uf), and know by data 
independence of 5 that u e S. Moreover, we can use the same bijection used for e + c u± 
to prove that cEb. 

Lemma 2. Any data structure S defined in our framework is closed under projection. 

Proof. Let u e S and let D c D. Since u e S, there is a sequence of applications of rules 
starting from the empty word e which can derive u. We remove from this derivation 
all the rules corresponding to a data-value x i D, and we project all the sequential 
executions appearing in the derivation on the D. Since the predicates which appear in 
the conditions are all closed under projection, the derivation remains valid, and proves 
that u\o e S. 

Lemma 3. Let S = R \,... ,R n be a data structure and u a differentiated sequential 
execution. Then, 

u e S <=> proj(w) c |^J MRj 

ie{l,...,n] 

Proof. (=>) Using Lemma [2] we know that S is closed under projection. Thus, any 
projection of a sequential execution u of 5 is itself in S and has to match one of the 
rules R\,.. .,R„. 

(<=) By induction on the size of u. We know u e proj(M), so it can be decomposed 
to satisfy the conditions Guard of some rule R of S. The recursive condition is then 
verified by induction. 

Lemma 5. Let S be a data structure with rules R\,..., R„. Let e be a differentiated 
execution. IfS is step-by-step linearizable, we have (for any j): 

e E Rj} <=> proj(e) C J MR, 

i<i 


Proof. (=>) We know there exists u e S such that e C u. Each projection e' of e can be 
linearized with respect to some projection u' of u, which belongs to (J / MR, according 
to Lemma [3] 

(<=) By induction on the size of e. We know e e proj(e) so it can be linearized with 
respect to a sequential execution u matching some rule If, (k < j) with some witness x. 
Let e' — e \ x. 
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Since S is non-ambiguous, we know that no projection of e can be linearized to a 
matching set MR, with i > k , and in particular no projection of e'. Thus, we deduce that 
proj(e') E (Jest MR,, and conclude by induction that e' E p?i,.. 

We finally use the fact that S is step-by-step linearizable to deduce that e E |/?i,..., A 1 /,-] 
and e E [Si./?y] because k < j. 


Lemma 6. Let S be a data structure with rules R\,, R„. Let e be a differentiated 
execution. IfS is step-by-step linearizable, we have: 

e E S <=> V<?' e proj(e). e' E MR where R = last(e') 

Proof. (=>) Let e' e proj(e). By Lemma[5] we know that e' is linearizable with respect to 
MRj for some i. Since S is non-ambiguous, last(e') is the only rule such that e' E MR 
can hold, which ends this part of the proof. 

(<=) Particular case of Lemma0 

Theorem 1. Let S be a step-by-step linearizable and co-regular data structure and 
let I be a data-independent implementation. There exists a regular automaton Id such 
that: 

I E S <^> Jnyi = 0 

Proof. Let Idi ,..., Id,, be the regular automata used to show that R\,... ,R„ are co¬ 
regular, and let Id be the (non-deterministic) union of the Id,’s. 

(=>) Assume there exists an execution c £ In LR. For some i, e e Id,. From the 
definition of “co-regular”, we deduce that there exists e' e proj(e) such that e' % MR ,, 
where R , is the rule corresponding to e'. By Lemma[6] e is not linearizable with respect 
to S. 

(<=) Assume there exists an execution cel which is not linearizable with respect 
to S. By Lemma[6] it has a projection e' e proj(e) such that e' % MRj, where R , is the 
rule corresponding to e'. By definition of “co-regular”, this means that I n Id, 4- 0, and 
that I n Id + 0. 

8.3 Step-by-step Linearizability 

Lemma 4. Queue, Stack, Register, and Mutex are step-by-step linearizable. 

Proof. Even though we do not have a unique proof that the data structures are step- 
by-step linearizable, we have a model of proof which is generic, which we use for each 
data structure. The generic schema we use is the following: we let u' e /?,■] be a 

sequential execution such that h \ x E u' and build a graph G from u' , whose acyclicity 
implies that h E |/?i,..Then we show that we can always choose u' so that this 
G is acyclic. 

For better readability we make a sublemma per data structure. 

Lemma 8. Queue is step-by-step linearizable. 
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Proof. Let h be a differentiated history, and u a sequential execution such that h c u. 
We have three cases to consider: 

1) u matches R Enq with witness x: let h' = h\x and assume h' C |/?o> REnq ]■ Since u 
matches R Enq , we know h only contain Enq operations. The set p?o,/?£„ 9 ] is composed 
of the sequential executions formed by repeating the Enq method events, which means 
that h C [/? 0 , 

2) u matches R Enq Deq with witness x: let W = h\x and assume h’ c p? 0 , R Enq , R En qDeq\- 
Let u' e [R 0 ,REnq,REnqDeq] such that h’ c u'. We define a graph G whose nodes are the 
operations of h and there is an edge from operation o\ to 02 if 

1 . o\ happens-before 02 in h, 

2 . the method event corresponding to o\ in u' is before the one corresponding to 02 , 

3. o\ — Enq(x) and o 2 is any other operation, 

4. o\ — Deqix) and o 2 is any other Deq operation. 

If G is acyclic, any total order compatible with G forms a sequence 112 such that h c u 2 
and such that u 2 can be built from u' by adding Enq(x) at the beginning and Deqix) be¬ 
fore all Deq method events. Thus, u 2 e lRo,R E nq,R E nqDeq] and h c lRo,R E nq,R E nqD e q]- 
Assume that G has a cycle, and consider a cycle C of minimal size. We show that 
there is only one kind of cycle possible, and that this cycle can be avoided by choosing u' 
appropriately. Such a cycle can only contain one happens-before edge (edges of type|T}. 
because if there were two, we could apply the interval order property to reduce the cycle. 
Similarly, since the order imposed by u' is a total order, it also satisfies the interval order 
property, meaning that C can only contain one edge of type [2] 

Moreover, C can also contain only one edge of type [3] otherwise it would have to 
go through Enq(x) more than once. Similarly, it can contain only one edge of typeQ] It 
cannot contain a type0edge Enq(x) —> o\ at the same time as a type[4]edge Deqix) —> 
02 , because we could shortcut the cycle by a type[3]edge Enq(x) —> o 2 . 

Finally, it cannot be a cycle of size 2. For instance, a type [2] edge cannot form a 
cycle with a type|T]edge because h' E 11 '. The only form of cycles left are the two cycles 
of size 3 where: 

- Enq(x) is before o 1 (type [3]), o\ is before o 2 in u' (type [2]), and o 2 happens-before 
Enq(x): this is not possible, because h is linearizable with respect to u which 
matches R Enq Deq with x as a witness. This means that u starts with the method 
event Enqix), and that no operation can happen-before Enq(x) in h. 

- Deq(x) is before o 1 (typeQ}, o\ is before o 2 in u' (typeO, and o 2 happens-before 
Deq{x ): by definition, we know that cq is a Deq operation; moreover, since h is 
linearizable with respect to u which matches R EnqE > e q with x as a witness, no Deq 
operation can happen-before Deq(x) in h, and o 2 is an Enq operation (or Enq). Let 
d\, d 2 e D such that Deq{d\) = o\ and Enq{d 2 ) = o 2 . 

Since o\ is before o 2 in 11 ', we know that d\ and d 2 must be different. Moreover, 
there is no happens-before edge from o\ to o 2 , or otherwise, by transitivity of the 
happens-before relation, we’d have a cycle of size 2 between o \ and Deqix). 

Assume without loss of generality that o\ is the rightmost Deq method event which 
is before o 2 in n', and let o \,..., of, be the Enq (or Enq) method events between o\ 
and o 2 . There is no happens-before edge o\ </,/, of because by applying the interval 
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order property with the other happens-before edge oy <hb Deq(x), we’d either have 
o 1 <hb Deq(x) (forming a cycle of size 2) or 02 <hb o\ (not possible because h' E u' 
and o\ is before 02 in it'). 

Let if be the sequence u' where Deq(x) has been moved after 02 . Since we know 
there is no happens-before edge from Deq(x) to oi, or to oy, we can deduce that: 
h' E it' 2 . Moreover, if we consider the sequence of deductions which proves that 
u r e \Rq,R-E nq,REnqDeq\, we can alter it when we insert the pair Enq(d\) and o\ — 
Deq(di) by inserting o \ after the ofs and after oy. instead of before (the conditions 
of the rule R Enq Deq allow it). 

This concludes case 2), as we’re able to choose u' so that G is acyclic, and prove that 

h E \R ih Rpn/p REnqDcq\- 

3) u matches RDeqEmpty with witness x : let o be the DeqEmpty operation correspond¬ 
ing to the witness. Let h' — h\x and assume h' E Queue. Let L be the set of operations 
which are before o in u, and R the ones which are after. Let Dp be the data-values ap¬ 
pearing in L and Dp be the data-values appearing in R. Since it matches RDeqEmpty- we 
know that L contains no unmatched Enq operations. 

Let u' e Queue such that h' E u'. Let u' L = u'\ d l and u' R = u’\d r - Since Queue 
is closed under projection, u’ L , u' R £ Queue. Let 112 — u' L • o • u' R . We can show that 
U 2 e Queue by using the derivations of u' L and u' R . Intuitively, this is because Queue is 
closed under concatenation when the left-hand sequential execution has no unmatched 
Enq method event, like u' L . 

Moreover, we have h C U 2 , as shown in the following. We define a graph G whose 
nodes are the operations of It and there is an edge from operation o\ to 02 if 

1 . 0 \ happens-before 02 in h, 

2 . the method event corresponding to o\ in tty is before the one corresponding to oy. 

Assume there is a cycle in G, meaning there exists o\,oy such that o\ happens-before 
oy in h, but the corresponding method events are in the opposite order in tty. 

- If 01 ,02 € L, or o\,oy e R , this contradicts W C «'• 

- If o 1 & R and oy £ L , this contradicts h c u. 

- If o\ £ R and oy = o, or if o\ - a and oy £ L , this contradicts h c u. 

This shows that h c tty. Thus, we have h c Queue and concludes the proof that the 
Queue is step-by-step linearizable. 

Lemma 9. Stack is step-by-step linearizable. 

Proof. Let h be a differentiated history, and u a sequential execution such that h C u. 
We have three cases to consider: 

1) (very similar to case 3 of the Queue) it matches Rp„ s hPop with witness x: let a 
and b be respectively the Push and Pop operations corresponding to the witness. Let 
h' — h \ x and assume h' E \Rp U shPop\- Let L be the set of operations which are before 
b in u, and R the ones which are after. Let Dp be the data-values appearing in L and Dp 
be the data-values appearing in R. Since u matches Rp„ s hPop , we know that L contains 
no unmatched Push operations. 
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Let u' e iRpushPopj such that h' C u'. Let u' L - u'\ Dl and u' R = u'\ Dr . Since {Rp us hPo P } 
is closed under projection, u' L , u' R e \Rp us hPo P \- Let «2 = a ■ u' L - b • u' R . We can show that 
W 2 e by using the derivations of u' L and u' R . 

Moreover, we have h c M 2 , because if the total order of it 7 didn’t respect the happens- 
before relation of 117 , it could only be because of four reasons, all leading to a contradic¬ 
tion: 

- the violation is between two L operations or two R operations, contradicting /;' c 11 ' 

- the violation is between a L and an R operation, contradicting h C u 

- the violation is between b and another operation, contradicting /; L it 

- the violation is between a and another operation contradicting h c u 

This shows that h C \Rp U shPop\ and concludes case 1. 

2 ) n matches Rp us h with witness x: similar to case 1 

3) u matches Rp op Empty with witness x: identical to case 3 of the Queue 

Lemma 10. Register is step-by-step linearizable. 

Proof. Let h be a differentiated history, and it a sequential execution such that /; c u and 
such that u matches the rule Rwr with witness x. Let a and b \,..., b s be respectively 
the Write and Read's operations of h corresponding to the witness. 

Let /;' = h \ x and assume h' C p?w«]- Let u' e [fi’ws] such that h' C u'. Let 
«2 = a ■ b\ ■ bz • ■ • b s ■ u'. By using rule Rwr on u', we have ui e Moreover, we 

prove that h L M 2 by contradiction. Assume that the total order imposed by M 2 doesn’t 
respect the happens-before relation of h. All three cases are not possible: 

- the violation is between two u' operations, contradicting /;' c m', 

- the violation is between a and another operation, i.e., there is an operation o which 
happens-before a in h, contradicting h C n, 

- the violation is between some bj and a u' operation, i.e., there is an operation o 
which happens’before b , in h, contradicting h C m. 

Thus, we have h c M 2 and h c which ends the proof. 

Lemma 11. Mutex is step-by-step linearizable. 

Proof. Identical to the Register proof, expect there is only one Unlock operation (b), 
instead of several Read operations (b\,..b s ). 

8.4 Regularity 

Lemma 7. Queue, Stack, Register, and Mutex are co-regular. 

Proof. We have a generic schema to build the automaton, which is first to characterize 
a violation by the existence of a cycle of some kind, and then build an automaton rec¬ 
ognizing such cycles. For some of the rules, we prove that these cycles can always be 
bounded, thanks to a small model property. For the others, even though the cycles can 
be unbounded, we can still build an automaton 
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(Queue) The empty automaton proves that Rq and R Enq are regular, as there is no 
execution e' such that last(e') = R and e' % MR for R e {Rq, R En q}- The proofs for 
REnqDeq and RneqEmpty are more complicated and can be found respectively in Lemma[T 6 l 
and Lemma [T9l 

(Stack) The proofs can be found in Appendix l8.7l 

(Register and Mutex) Similarly to the rule REnqDeq, we can reprove Lemma[T2l( with 
sublemmas [13] [14] and IT5T ) to get a small model property, and build an automaton for 
the small violations. 

8.5 Regularity of R Enq Deq 

Lemma 12. Given a history h, ifid\,dy e B/„ h^.d,] E REnqDeq, then h c R Enq Deq- 

Proof. We hrst identify constraints which are sufficient to prove that h c R E nqDeq- 

Lemma 13. Let h be a history cmd x a data value o/O/,. IfEnq(x) i Deq(x), and for all 
operations o, we have Enq(x) i o, and for all Deq operations o, we have Deq(x) i o, 
then h is linearizable with respect to MR En qDeq 

Proof. We define a graph G whose nodes are the element of h, and whose edges include 
both the happens-before relation as well as the constraints depicted given by the Lemma. 
G is acyclic by assumption and any total order compatible with G corresponds to a 
linearization of h which is in MR Enq Deq- 

Given d\,dy e D/,, we denote by d\ W],mr dy the fact that h^jj is linearizable 
with respect to R, by using d\ as a witness for the existentially quantified x variable. We 
reduce the notation to d\ W dy when the context is not ambigious. 

First, we show that if the same data value can be used as a witness for x for all 
projections of size 2 , then we can linearize the whole history (using this same data 
value as a witness). 

Lemma 14. For d\ e B/„ if'id + d\, d\ W d, then h C MR EnqEeq . 

Proof. Since id + d\. d\ W d, the happens-before relation of h respects the constraints 
given by Lemma[ 13] and we can conclude that h c MR EnqE)e q. 

Next, we show the key characterization, which enables us to reduce non-linearizability 
with respect to MR EnqE)eq to the existence of a cycle in the yf relation. 

Lemma 15. Ifh % MR Enq o eq , then h has a cycle d\ yf dy yf ... yf d m yf d\ 

Proof. Let d\ e O/,. By Lemma [T4l we know there exists dy e D/, such that d\ yf dy. 
Likewise, we know there exists c /3 e ."Dy, such that dy yf dy. We continue this construc¬ 
tion until we form a cycle. 

We can now prove the small model property. Assume h % R. By Lemma[l5l it has 
a cycle d\ yf dy yf ... yf d,„ yf d\. If there exists a data-value x such that Deq(x) 
happens-before Enq(x ), then h\{ x ) f REnqDeq, which contradicts our assumptions. 
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For each i, there are two possible reasons for which d t y4da nlod m ) + \. The first one 
is that Enq(dj) is not minimal in the subhistory of size 2 (reason (a)). The second one is 
that Deq d . is not minimal with respect to the Deq operations (reason (b)). 

We label each edge of our cycle by either (a) or (b), depending on which one is 
true (if both are true, pick arbitrarily). Then, using the interval order property, we have 
that, if djyf d(j mod m)+1 for reason (a), and dj y<f d ( j mod m)+1 for reason (a) as well, then 
either dj y( d (j mod m)+t , or dj yf d (i mod m)+] (for reason (a)). This enables us to reduce 
the cycle and leave only one edge for reason (a). 

We show the same property for (b). This allows us to reduce the cycle to a cycle 
of size 2 (one edge for reason (a), one edge for reason (b)). If d\ and d 2 are the two 
data-values appearing in the cycle, we have: h^ dudl ) % REnqDeq- which is a contradiction 
as well. 

Lemma 16. The rule REnqDeq is co-regular. 

Proof. We prove in Lemma IT2l that a differentiated history h has a projection h' such 
that last(/j') = REnqDeq and h' % MREnqDeq if and only if it has such a projection on 1 
or 2 data-values. Violations of histories with two values are: i) there is a value x such 
that Deq(x) happens-before Enq(x) (or Enq(x) doesn’t exist in the history) or ii) there 
are two operations Deq(x) in h or. Hi) there are two values x and y such that Enq(x) 
happens-before Enq(y), and Deq(y) happens-before l)eq(x) ( Deq(x) doesn’t exist in the 
history). 

The automaton XI R EllqDeq in Fig. [3] recognizes all such small violations (top branch 
for i, middle branch for ii, bottom branch for iii). 

Let I be any data-independent implementation. We show that 

d^REnqDeq Fl X ^ 0 die € T -t, C 6 : ptoj(^). luSttf' ) — REnqDeq E e f MREnqDeq 

(=>) Let e e I be an execution which is accepted by XI R EllqDeq - By data independence, 
let e I r a renaming such that e = r(e # ), and assume without loss of generality 
that r doesn’t rename the data-values 1 and 2. If e is accepted by the top or middle 
branch of XI R EnqDeq , we can project e 4 on value 1 to obtain a projection e' such that 
last(e') = REnqDeq and e' % MREnqDeq- Likewise, if e is accepted by the bottom branch, 
we can project e± on { 1 , 2 }, and obtain again a projection e' such that last(e') = REnqDeq 
and e' % MR EnqD eq- 

(<=) Let e± e I + such that there is a projection e' such that last(e') = REnqDeq and 
e' f MREnqDeq- As recalled at the beginning of the proof, we know e t _ has to contain a 
violation of type i. ii, or ii. If it is of type i or ii, we define the renaming r, which maps 
x to 1, and all other data-values to 2. The execution r{e±) can then be recognized by the 
top or middle branch of dRR EllqDeq and belongs to I by data independence. 

Likewise, if it is of type iii, r will map x to 1, and y to 2, and all other data-values 
to 3, so that r(ef) can be recognized by the bottom branch of dRR EnqDeq . 

8.6 Regularity of R Deq Empty 

We first define the notion of gap, which intuitively corresponds to a point in an execution 
where the Queue could be empty. 
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Definition 9. Let h be a differentiated history and o an operation ofh. We say that h has 
a gap on operation o if there is a partition of the operations ofh into LWfl satisfying: 

- L has no unmatched Enq operation, and 

- no operation ofR happens-before an operation of L or o, and 

- no operation of L happens-after o. 

Lemma 17. A differentiated history h has a projection h' such that lastC/i') = RoeqEmpty 
and h' MRoeqEmpty if and only there exists a DeqEmpty operation o in h such that 
there is no gap on o. 

Proof (=>) Assume there exists a projection W such that last (/;') = RoeqEmpty and 
h' f MR DeqEmpty ■ Let o be a DeqEmpty operation in h' (exists by definition of last). 

Assume by contradiction that there is a gap on o. By the properties of the gap, we 
can linearize W into a sequential execution u ■ o ■ v where u and v respectively contain 
the L and R operations of the partition. 

(<=) Assume there exists a DeqEmpty operation o in h such that there is no gap on 
o. Let h' be the projection which contains all the operations of h as well as o, except the 
other DeqEmpty operations. 

Assume by contradiction that there exists a sequential execution w e MRoeqEmpty 
such that h' c w. By definition of MR DeqEmpty , w can be decomposed into u ■ o ■ v such 
that u has no unmatched operation. Let L be the operations of u, and R the operation of 
v. Since h' c w, the partition LW R forms a gap on operation o. 

We exploit the characterization of Lemma [FT] by showing how we can recognize 
the existence of gaps in the next two lemmas. First, we define the notion of left-right 
constraints of an operation, and show that this constraints have a solution if and only if 
there is a gap on the operation. 

Definition 10. Let h be a distinguished history, and o an operation of h. The left-right 
constraints ofo is the graph G where: 

- the nodes are D;,, the data-values ofh, to which we add a node for o, 

- there is an edge from data-value d\ to o if Enq(d\) happens-before o, 

- there is an edge from o to data-value d\ ifo happens-before Deq(di), 

- there is an edge from data-value d\ to dy if Enq(d\) happens before Deq(dj). 

Lemma 18. Let h be a differentiated history and o an operation of h. Let G be the 
graph representing the left-right constraints of o. There is a gap on o if and only if G 
has no cycle going through o. 

Proof (=>) Assume that there is a gap on o, and let L l±) R be a partition corresponding 
to the gap. Assume by contradiction there is a cycle d m d\ —■> o —* d m in G 

(which goes through o). By definition of G, and since o —> d m , and by definition of a 
gap, we know that all operations with data-value d m must be in R. Since d m —» d m - \, 
the operations with data-value d m -\ must be in R as well. We iterate this reasoning until 
we deduce that d\ must be in R, contradicting the fact that d\ —» o. 

(<=) Assume there is no cycle in G going through o. Let L be the set of operations 
having a data-value d which has a path to o in G, and let R be the set of other operations. 
By definition of the left-right constraints G, the partition L^tiR forms a gap for operation 
o. 
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Corollary 1. A differentiated history h has a projection h' such that last (h 1 ) — RneqEmpty 
and h' (£ MRoeqEmpty if and only if it has a DeqEmpty operation o and data-values 
d\,... ,d m € D* such that: 

- Enq(di) happens-before o in h, and 

- Enq(dj) happens before Deq(d ,-\) in h for i > 1, and 

- o happens-before Deq{d m ), or Deq(d m ) doesn’t exist in h. 

We say that o is covered by d\,..., d m . 

Proof. By definition of the left-right constraints, and following from Lemmas [FT] and 

m 

Lemma 19. The rule RDeqEmpty is co-regular. 

Proof. See Section [4] 

8.7 Regularity of the Stack rules 

Lemma 20. A differentiated history h has a projection h' such that last(/?') = Rp U shPop 
and h’ t£ MRp„ s hp 0 p if and only if there exists a projection such that lastf/z') = Rp U shPop 
and either 

- there exists an unmatched Pop(d) operation in h', or 

- there is a Pop(d) which happens-before Push(d) in h', or 

- for all Push(d) operations minimal in h', there is no gap on Pop(d) in h' \ d. 

Proof. Similar to Lemma [171 

Lemma 21. A differentiated history h has a projection h' such that lastf/;') = Rp us hPop 
and h' ^ MRp us i t p 0 p if and only if either: 

- there exists an unmatched Pop(d) operation, or 

- there is a Pop(d) which happens-before Push(d), or 

- there exist a data-value d e B /, and data-values d\,... ,d m 6 D/ ? such that 

• Push(d) happens-before Push(dj) for every i, 

• Pop(d) is covered by d i,..., d,„. 

Proof. (<=) We have three cases to consider 

- there exists an unmatched Pop(d ) operation: define li' = h\^}, 

- there is a Pop(d) which happens-before Push(d): define h' = h\\,i\, 

- there exist a data-value d e B/, and data-values d\,..., d m e O/, such that 

• Push(d) happens-before Push{dj) for every i 

• Pop(d) is covered by d\,, d,„. 

Define h’ = h\\,i.di....,d,„\. We have last(/?') = Rp us hPop because li' doesn’t contain 
PopEmpty operations nor unmatched Push operations. Assume by contradiction 
that h' E MRp us hp op , and let w e MRp us hp 0 p such that h' E u. Since Pushed) 
happens-before Push(dj) (for every i) the witness x of vv e MRp HS hp op has to be the 
data-value d. This means that w = Push(d) ■ u ■ Pop(d) ■ v for some u and v with no 
unmatched Push. 

Thus, there is a gap on operation Pop(d) in h'\d, and that Pop(d) cannot be covered 
by d\,..., d m . 
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(=>) Let h' be a projection of h such that last(7i') = Rp us hPop and h' % MRp us hp op . 
Assume there are no unmatched Pop(d) operation, and that for every d, Pop(d) doesn’t 
happens-before Push(d). This means that h' is made of pairs of Pushed) and Pop(d) 
operations. 

Let Push(d) be a Push operation which is minimal in h'. We know there is one, 
because we assumed that last (h') = Rp us hp op , and we know that there is a Push which 
is minimal because for every d , Pop(d) doesn’t happens-before Push(d). 

By Lemma[20j we know that there is no gap on Pop(d). Similarly to Lemma[T8land 
Corollary [T| we deduce that there are data-values d\,... ,d m e such that Pop(d) is 
covered by d\,... , d m . Our goal is now to prove that we can choose d and d\..... d m 
such that, besides these properties, we also have that Push(d) happens-before Push(d ,) 
for every i. Assume there exists i such that Push(d) doesn’t happen-before Push(di). We 
have two cases, either Pop(d) is covered by d \,..., d,- \, d, , \,..., d m , in which case we 
can just get rid of a?,; or this is not the case, and we can choose our new d to be d, and 
remove d, from the list of data-values. We iterate this until we have a data-value d e B/, 
such that 

- Push(d) happens-before Push(dj ) for every ;, 

- Pop(d) is covered by d \,..., d m . 

Lemma 22. The rule Rp us hPop is co-regular. 

Proof. The automaton Fig.[4]recognizes the violations given by Lemmal2Tl The proof 
is then similar to Lemma[l9l 

Lemma 23. The rule Rp us h is co-regular. 

Proof. We can make a characterization of the violations similar to LemmaETl This rule 
is in a way simpler, because the Push in this rule plays the role of the Pop in Rp us hPop- 

Lemma 24. The rule Rp op Empty is co-regular. 

Proof. Identical to Lemma fl9l (replace Enq by Push , Deq by Pop , and DeqEmpty by 
PopEmpty). 

8.8 Regular automata used to prove regularity 
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call Deq( 1) 

M(1),M(2) M(1),M(2) M(1),M(2) 



call Deq( 1) 

M(3) M(3) M(3) M(3) M(3) 



call Deq( 2) 


Fig. 3. A non-deterministic automaton recognizing R-E,,qDeq violations. The top branch recognizes 
executions which have a Deq with no corresponding Enq. The middle branch recognizes two 
Deq's returning the same value, which is not supposed to happen in a differentiated execution. 
The bottom branch recognizes FIFO violations. By the closure properties of implementations, we 
can assume the call Deq(2) are at the beginning. 



Fig. 4. An automaton recognizing Rp„ s i,p 0 p violations. Here we have a Pusli( 2) operation, whose 
corresponding Pop( 2) operation is covered by Push(l)/Pop(l ) pairs. The Push(2) happens- 
before all the pairs. Intuitively, the element 2 cannot be popped from the Stack there is always at 
least an element 1 above it in the Stack (regardless of how linearize the execution). 
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